Purpose
  • To outline the processes in the business.
  • To define the boundaries of the business to be modeled.
  • To define who and what will interact with the business.
  • Create diagrams of the business use-case model.
  • Develop a survey of the business use-case model.
Steps
Input Artifacts:
  • Vision, if any exists at this point
  • Glossary, if any exists at this point
Resulting Artifacts:
Worker: Business-Process Analyst
Work Guidelines:
Tool Mentors

Workflow Details:

Find Business Actors To top of page

A business actor candidate is any individual, group, organization, company or machine that interacts with the business. Here are some categories where you can find business actors:

  • Customers.
  • Partners.
  • Suppliers.
  • Authorities (legal, regulatory, etc.).
  • Subsidiaries.
  • Owners and investors. Decide whether the board of directors should be part of the business or modeled as an actor.
  • Information systems outside the business.

If the business you are going to model is part of a large company, these categories may also contain business actors.

  • Other parts of the company.
  • Individual roles within other departments.

Name each business actor so that its name denotes its role in the business. Define each business actor by writing a brief description that includes its responsibility and why it interacts with the business.

See also Guidelines: Business Actor.

Find Business Use Cases To top of page

To find the primary business use cases, consider what value each business actor gets from the business. Start with the primary and most important business actors ù the customers ù and ask yourself:

  • What are the primary services a customer is given by the business?

A good tip is to study the lifecycle of the customer. What is the first contact a customer has with the business? What stages or states does the customer go through in relation to the business?

Processes of more supporting character to the business (contains activities that do not benefit the customer directly) can also be represented as business use cases. Look for the following kinds of activities:

  • Development and maintenance of the staff.
  • Development and maintenance of the IT within the business.
  • Development and maintenance of the office.
  • Security.
  • Legal activities.

Processes of management character can be represented as business use cases, even though it is more rare that they are interesting from an information-system perspective. These processes are found by looking for activities that have to do with managing the business as a whole. A process of this kind normally interacts with the owner actor(s). Consider what the owner actor(s) gets from the business. Look for the following kind of activities:

  • Develop and provide information about the business to owners and investors.
  • Set up long-term budget goals.
  • Coordinate and prioritize between the other use cases in the business.
  • Create new processes in the business.
  • Monitor the processes in the business.

The lifecycle of a process of this kind often span one fiscal year.

Another way to find business use cases is to have domain experts describe every activity in the existing business, and then group these activities into business use cases.

Name and briefly describe the use cases.

See also Guidelines: Business Use-Case Model and Guidelines: Business Use Case.

Prioritize Business Use Cases To top of page

Once you have identified the business actors and business use cases, you must prioritize which business use cases are of interest to describe in any detail. This involves the following:

  • If you perform business engineering in order to find requirements on information systems, determine which business use cases are of interest to the intended system. These need to be described in detail (see Activity: Detail a Business Use Case).
  • For business use cases where you cannot clearly see whether they are relevant or not from an information-system perspective, develop a step-by-step description before you make a decision whether to include them or not.

Develop an Outline of the Workflow of Business Use Cases To top of page

Often, you need an outline of the workflow to understand the purpose of the business use case. This can be done in a step-by-step format. The person who will later specify the business use case û even if it is the same person û will need this step-by-step description.

Example:

The first draft of a step-by-step workflow description of the business use case Individual Check-in might look as follows.

  • Passenger enters the queue to the check-in counter.
  • Passenger gives ticket to check-in agent.
  • Check-in agent validates ticket.
  • Check-in agent registers baggage.
  • Check-in agent reserves seat for the passenger.
  • Boarding card is printed.
  • Check-in agent gives passenger boarding card.
  • Passenger leaves the check-in counter.

Note that this is a first draft, so it may very well lack activities that will be discovered later. You may also include alternative flows in this draft.

Concentrate on the most important business use cases, those that represent the highest improvement potential. Can its scope be increased so that work originally done by the customerûor by no oneûis now done by the target organization? Or can the scope be diminished so that the customer now does work previously done by the target organization? A business use case is improved if it serves the customer better, which implies that it becomes simpler, produces better products, offers shorter lead times, and so on. 

For each business use case, set up measurable goals that can be used to verify whether you have succeeded. Later, when the new target organization is established, you can use these goals to continuously measure how the business use cases are functioning and being improved.

See also Guidelines: Business Use Case.

Describe How Business Actors and Use Cases Interact To top of page

Establish which business actors interact with the business use case by defining a communicates-association between them. If it is important to show who initiated the communication, you can add navigability to the association.

See also Guidelines: Communicates-Association in the Business Use-Case Model.

Package Business Use Cases and Actors To top of page

If you have many business use cases, you can divide them into packages to make the documentation easier to understand.

Present the Business Use-Case Model in Use-Case Diagrams To top of page

Use-case diagrams illustrate the combination of business actors, business use cases, and their relationships. A diagram may contain any of the following:

  • A business actor and all the business use cases with which he interacts.
  • Business use cases that interact with the same business actors.
  • Business use cases that are usually performed in a sequence.
  • Business use cases that belong to the same use case package.
  • The most important business use casesùthis diagram can function as a summary of the complete business use-case model, and it can help in reviewing the model.

See also Guidelines: Use-Case Diagram in the Business Use-Case Model.

Develop a Survey of the Business Use-Case Model To top of page

The Survey Description of the business use-case model should convey the following information:

  • The purpose of the business being described.
  • Typical sequences in which the business use cases are employed.
  • What parts of the business are not included in the business use-case model.

Evaluate Your Results To top of page

You should check the business use-case model at this stage to verify that your work is on track, but not review the model in detail. You should also consider the checkpoints for the business use-case model while you are working on it. The interested parties will have to determine:

  • If all necessary business use cases are identified.
  • If any unnecessary business use cases are identified.
  • If the behavior of each business use case is described in the right order.
  • If each business use case's workflow is as complete as it could be at this stage.
  • If the Survey Description of the business use-case model makes it understandable.

For more issues to review, see Checkpoints: Business Use-Case Model, Checkpoints: Business Use Cases, and  Checkpoints: Supplementary Business Specifications

 

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process